Field of the Invention
The invention relates to a method for manipulating a bus communication of a control device, whereby the bus communication includes at least one bus hardware-independent first communication layer and at least one bus hardware-dependent second communication layer.
Description of the Background Art
Methods for manipulating the bus communication of a control device are often used when a control device, which is connected or to be connected to other communication partners via a bus, is to be tested, particularly when the communication behavior of the control device itself is the object of the test. Methods for manipulating the bus communication of a control device are often used for this reason to test a control device and for testing the control device behavior in the event of error. Such methods are known, for example, as part of the so-called restbus simulation, in which real control devices are used in a hardware- and software-based simulated communication environment and their behavior is tested. Such methods are also known, however, as part of the restbus simulation of virtual control devices.
The first and the second communication layer can comprise additional sub-communication layers. The term “communication layer” is to be understood here substantially in the same sense as it is used, according to general understanding, for network protocols or bus protocols. Each communication layer typically provides functionalities to receive information from an adjacent communication layer and to pass it on prepared to another adjacent communication layer. With respect to the aforementioned division into a bus hardware-independent first communication layer and a bus hardware-dependent second communication layer, this means specifically that the first communication layer encodes at least one piece of information in a first protocol data unit and transmits it to the second communication layer and/or that the first communication layer receives the first protocol data unit from the second communication layer and decodes the information from the first protocol data unit. Information in the bus hardware-independent first communication layer refers here typically to an application-oriented datum, for example, a measured value, which has been recorded by the control device and is sent via a bus to another bus participant, or, for example, a variable calculated by the control device. The specific bus used in the particular case is not important for the methods being discussed either in the state of the art or in the method of the invention; the method can be used with any data buses. Examples of bus standards often used in industrial practice are CAN, LIN, or FlexRay. The information is encoded in the send direction, therefore from the first communication layer to the second communication layer, this means, for example, expanded by certain administrative information, and forwarded further to layers closer to the bus and in the present case, therefore, to the second communication layer. In the send and encode direction, the information is packed in the aforementioned protocol data unit. In the receive or decode direction, administrative information is correspondingly removed from the packed information, therefore the first protocol data unit, and finally the information is provided as such. If the first communication layer is capable of both sending and receiving, both the functionality of encoding and the functionality of decoding are implemented. The first communication layer for this reason is bus hardware-independent, because only such services are implemented in it that are independent of the specific bus hardware. In other words, the services realized in the bus hardware-independent layer are either independent of the bus system or dependent on the bus system, but not dependent on the specific bus hardware. The bus-independent first communication layer therefore lies above the communication hardware abstraction layers. For the example of a control device realized according to the AUTOSAR standard, the bus hardware-independent first communication layer then comprises application layer, runtime environment (RTE), and communication services (also including bus system-dependent parts, such as, e.g., CAN transport protocol or FlexRay transport protocol), but not the bus hardware-dependent driver layers, such as, e.g., CAN interface or FlexRay interface.
The bus hardware-dependent second communication layer as well comprises functionalities that realize the transmission of data in the send direction, therefore in the direction to the bus, or in the receive direction, therefore in the direction to the first communication layer, or the transmission of data in both directions. This means that the second communication layer generates bus hardware-dependent bus information from the first protocol data unit or from an additional protocol data unit derived from the first protocol data unit for transmission via the bus (send direction), and/or that the second communication layer generates the first protocol data unit or an additional protocol data unit, from which the first protocol data unit can be derived (receive direction), at least from a bus hardware-dependent bus information. Apart from the first protocol data unit, accordingly there can also be additional protocol data units, which are either derived from the first protocol data unit or from which the first protocol data unit can be derived. This takes into account only the fact that the second communication layer can comprise a plurality of sub-communication layers or protocol layers, each of which generates its corresponding protocol data unit, as has been explained in regard to the first protocol data unit. In the send direction, additional administrative information is typically added to each additional protocol data unit and in the receive direction the additional protocol data units are extracted in sub-communication layers or protocol layers until ultimately the first protocol data unit is obtained, from which the information is ultimately obtained in the first communication layer.
During the testing of control devices and the bus communication of control devices, there is interest in carrying out the testing as realistically as possible in order to obtain as meaningful a test result as possible. In regard to the control device this condition can be met in that in a testing environment merely the control device is used that corresponds in every respect to the series control device to be used later, which therefore has series hardware as well as series software.
For the testing of a real control device, other communication partners are frequently emulated within the scope of a restbus simulation on a hardware-in-the-loop simulator (HIL simulator), whereby not all communication partners need to be simulated, and some of the other communication partners can also be actually present. In the case of this restbus simulation also present in any event, errors can be generated relatively simply in the simulated restbus part, but errors cannot be simply injected between actually present control devices. If the communication between real control devices is to be manipulated as well, this is often realized with an error gateway. In an error gateway, in addition to the normal bus operating fault-free, a second “error bus” is provided, which in the case of error takes effect between two real control devices. The error gateway then mediates between the normal bus and the error bus, whereby the error gateway receives and decodes the data to be manipulated in the error case to be tested until such a protocol data unit is present in which an error is to be introduced, after which the manipulated message is again encoded and supplied to another control device via the error bus. It is readily evident that the manipulating of the bus communication of a control device via an error gateway is decidedly costly. Moreover, the restbus simulation with real control devices always requires that the control device is present also in its series version or at least as a hardware realization (so-called pre-series); this makes testing of the bus communication of a control device at an earlier time virtually impossible. Another fact is that the code, later used in the actual control devices, is not implemented in the restbus model of a simulated control device on an HIL simulator, so that the manipulated and tested bus communication does not correspond to the later actually realized bus communication.
The so-called virtual control devices initiate the testing exactly here. In contrast to the control device model of a restbus simulation, the code of a virtual control device already contains components of the series control device code, which is to be used later in the control device hardware.
Software that emulates a real control device in a simulation scenario is therefore called a virtual control device. The virtual control device in this case comprises, for example, the component of the application software, the runtime environment, and parts of the basic software as a serial control device code.
A virtual control device model is tested, for example, on a standard PC in an offline simulation or on a real-time simulator. In this regard, realistic effects such as the communication behavior are to be analyzed in the simulation.